Classifying, disabling and transmitting form fields in response to data entry

ABSTRACT

An attachment integrated claims (AIC) system includes an e-mail form (with specific fields that must be filled out) that adjusts itself, in both information required and formatting, to meet the demands of the receiving party. It is particularly advantageous for Electronic Data Interchange (EDI) situations where a user must send similar (but not necessarily identical) messages to several organizations. This is particularly important where, once an e-mail is received by those organizations, the information in the message must be digitally integrated into differing legacy information systems. In other words, the AIC system permits transmission of a dynamic claim form and integrated attachment to an insurance carrier via a non-clearinghouse communications channel. An AIC system including several computers connected via a communications channel, an electronic file, and an operating method therefor are also described.

This is a continuation of application Ser. Nos. 08/824,010 (NOW U.S.Pat. No. 6,003,007), 08/823,977 (NOW ABANDONED), and 08/823,978 (NOWABANDONED), all of which were filed on Mar. 25, 1997, application Ser.No. 09/232,805 (NOW U.S. Pat. No. 6,076,066), which was filed on Jan.19, 1999, as a continuation of application Ser. No. 08/824,010 (NOW U.S.Pat. No. 6,003,007), application Ser. No. 09/587,284 (NOW U.S. Pat. No.6,199,115), which was filed on Jun. 5, 2000 as a continuation ofapplication Ser. No. 09/232,805 (NOW U.S. Pat. 6,076,066), andapplication Ser. No. 09/745,489 (NOW U.S. Pat. No. 6,343,310), which wasfiled on Dec. 26, 2000 as a continuation of application Ser. No.09/587,284 (NOW U.S. Pat. No. 6,199,115). All of the above-identifiedapplications claim priority from Provisional Application No. 60/014,427,which was filed on Mar. 28, 1996.

BACKGROUND OF THE INVENTION

The present invention relates generally to an attachment integratedclaims (AIC) system for preparing and processing forms with integratedattachments. More specifically, the present invention relates to aCustomizable Claim Form, i.e., a Dynamic Claim Form (DCF) suitable foruse with an AIC system. A method of operating a totally digital AICsystem while employing a DCF is also disclosed.

High administrative costs for filing and processing health insuranceclaims have been the bane of the health insurance industry from itsinception. Over the years, many attempts have been made to develop afaster and more cost effective claims processing system. Three stages inthis development effort are described in the following correspondinglynumbered paragraphs.

(1) The original system involved hard copy paper claims only, withtransmission and all processing done manually. Originally, an insuranceclaim was filed by the patient or the health care provider filling out apaper form. The completed paper form was then mailed to the insurancecompany. At the insurance company, the paper claim form went through aseries of administrative steps, all the time remaining as a hard copypaper object. When a decision was made, the decision was written up andarchived with the claim form; a hard copy was also sent to the patientand/or provider along with the payment.

(2) The first significant advancement resulted from the introduction ofthe mainframe computer. This allowed for electronic processing within agiven insurance company, i.e., once the claim was on the computer insidethe company, the paper form could be dispensed with. Computerization isa highly effective way of reducing administrative overhead in claimsprocessing.

Thus, mainframe computers were purchased and installed internally at theinsurance companies. Since these computers were intended for internaluse only, each company thought only of its own needs and eitherdeveloped proprietary claims processing software or had claimsmanagement software purchased from an outside source customized to meetthe insurance company's claims processing methodology. While the claimsmanagement software for a number of insurance companies would be writtenin the same high-level programming language, e.g., COBOL, the similaritybetween software programs often ended there.

There were many virtues to these early systems, primarily with respectto decreased administrative costs, but a major drawback was that thedata for each “paper” claim had to be entered into the computer to forman electronic claim. This necessitated the manual transcription ofexactly the same information that had been entered into the originalpaper claim before it was sent to the insurance company.

(3) The next advancement was the electronic filing of claim forms. Thiswas made possible by the introduction of the personal computer and modeminto the provider's office. The main purpose of this stage was toeliminate the manual re-entry of information into the insurance companymainframe.

The basic idea was to have the providers fill out an electronic claimform, instead of a paper claim form. This electronic form, which wouldbe stored in the memory of their PCs, would then be transmitted, as acomputer file, to the insurance company. It could then be integrateddirectly into the electronic claims processing system without the manualre-entry of data. Thus, the technology existed to produce a system thatcomputerized the overall filing and processing of the insurance claimfrom the point of entry, the provider's office, to the final report ofthe claims adjuster.

Although the idea was straightforward, implementation was not. Two basicproblems had to be overcome in order to create a viable system. First,the information contained in the electronic claim form had to beintegrated into the claims processing software at the insurance company.Second, a majority of providers have to be able to interface with amajority of insurance companies, i.e., insurance company mainframecomputers. However, because of the way computers were introduced intothe insurance industry originally (stage #2), there was no industry-widestandard, i.e., the legacy mainframe computers of the differentinsurance companies were incompatible. This was true both with respectto the type of software used and with respect to the information thateach company required on its claim form.

One attempt to deal with these problems was the creation, by aconsortium of insurance companies, of the National ElectronicInformation Corporation (NEIC). NEIC's basic function is that of aclearinghouse. It acts as a common interface between the insurancecompanies and the service providers. It also establishes rigid standardsthat must be met in order to transmit an electronic claim form to aninsurance company. In practice, the service provider sends an electronicclaim to a vendor, who performs a service such as screening of the form.The vendor then transmits the form to NEIC, which then re-transmits itto the patient's insurance company. Since it is a computer file, theinformation in the electronic claim form can then be entered directlyinto the company's mainframe claims processing system, without themanual re-entry of data, and then processed.

Thus, a coherent system was created that allows for the electronicfiling, transmission, and processing of insurance claims. This system isemployed by thousands of providers and hundreds of insurance companies.

NEIC was designed to act as a clearinghouse for claims that are 100%text and that conform to very restrictive formats. For claims that meetthese conditions it functions well, resulting in substantial savings onadministrative costs for the insurance companies. It has been estimatedthat going to this third stage system results in savings of as much as60% in claims processing costs.

However, there are many claims that do not meet these conditions. Thesewould include claims that require additional text information that doesnot fit into the prescribed format and/or claims that require non-textinformation. In general, these are called “claims with attachments.”“Attachments” are any additional information that must be sent with the“standard text claim form.” This could include: pictures, graphs,additional text not allowed on the standard claim form, soundrecordings, etc.

An example of such a claim would be the PAC (Prior Approval Claim),which may be alternately denoted as a “Pretreatment Claim.” These areclaims that are sent to the insurance carrier before a procedure isperformed. For example, pretreatment claims are often required by dentalinsurance companies on any procedure over a specified amount, e.g.,$200. The aspect of this type of claim which renders it incompatiblewith the present electronic claim processing system is that theinsurance companies require that additional medical evidence beincluded, i.e., attached to, the text part of the claim form. In anexemplary case, the additional medical evidence is an x-ray.

The goal of the insurance company is to review the claim, i.e., both thetext form and attachment, and to do so in a cost-effective manner. Thenatural next stage in the development of claims processing systems is toattempt to computerized this process.

Scanners are now available that can digitize a dental x-ray, i.e.,convert it into a computer file that can be viewed on a monitor.Nevertheless, transforming the medical evidence into digital form is notenough to facilitate electronic processing of claims with attachments.One must also take into consideration the existing claims processinginfrastructure, i.e., the legacy infrastructure.

The difficulty with trying to include a digitized x-ray for processingwith an electronic claim form, within the current infrastructure, ismultifaceted. First, NEIC does not at the present time allow this typeof information to be transmitted through NEIC to the insurancecompanies. Second, with the current system, the claims adjusters accessclaims information through terminals connected to mainframes. However,there is the inherent problem of displaying images on mainframecomputers. This is especially true of mainframe computers runningsoftware written in business programming languages such as COBOL. Itmight be thought that a solution to this problem would be to replace theterminal with a PC. Although many personal computers provide thegraphics support needed to display the digitized x-ray, there aresignificant problems in interfacing a PC with a mainframe computer. Forexample, in order to interface with the mainframe computer, PCs oftenrun terminal emulation software that permits the PC to act like adedicated, dumb terminal attached to the mainframe computer. Terminalemulation software is notoriously lacking in graphics capability.Finally, getting a digitized x-ray from one provider to one insurancecompany is not all that is needed. Rather, what is really needed is anindustry-wide system by which a provider can interact with any insurancecompany. This results in a massive interfacing problem since there aremultitudes of insurance companies using different legacy hardwaresystems and company unique software.

Each time a way has been found to more fully utilize computers in claimsprocessing systems, the administrative costs associated with claimsprocessing have gone down. However, in the area of “claims withattachments,” no coherent industry-wide system exists that allows forthe integrated filing, transmitting and processing of these claimselectronically, i.e., via computers. Thus, when attachments arerequired, providers are forced to submit hard copy claim applications,while insurance companies labor under an administrative system that is ahybrid between a manual and an electronic system, i.e., a hybrid betweenstage #1 and stage #2. This hybrid system, which is described in greaterdetail below, is labor intensive, prone to problems, and slow. Forproviders, insurance companies, and patients, this is a time-consuming,costly and irritating process.

In short, there is at least one type of insurance claim that has not,until now, been able to avail itself of the third stage ofcomputerization, as described above. In fact, there are evendifficulties with the second stage. This group includes any claim whose“standard text form” must be accompanied by additional information thatdoes not fit into this standard format, e.g., x-rays, EKGs, additionaltext information such as Operating Room Reports, etc. In general, theseare referred to as “attachments.” One primary example of this would bePrior Approvals for dental procedures. Prior Approval Claim (PAC)applications are those claims that are submitted for the purpose ofreceiving a predetermination of benefits from the insurance company fora procedure that has not as yet been performed.

In the area of Prior Approval Claims, the goals of the insurancecompanies are to validate the necessity of the procedure and todetermine whether the patient's insurance policy obligates the insurancecompany to pay for such a procedure. This requires that the insurancecompany itself review the medical evidence. For an insurance company'sin-house dentist, for example, to make this appraisal, the dentist isrequired to review both the “text form” and the accompanying x-ray ofthe patient. However, the presence of a film x-ray means that electronicclaims methods cannot be implemented. The savings associated withelectronic claim processing is not available with respect to PriorApproval Claim forms.

Nationwide, there are approximately 200,000 dental PACs filed per week.Roughly, for every PAC application there will be eventually a FinalPayment claim (FPC) submitted when the medical procedure is completed.It is estimated that the overall administrative cost is $25 per PAC formand $10 for the Final Payment Claim. It is also estimated that if acoherent electronic system could be implemented, it would reduce theseadministrative costs to $15 per PAC and $5 per Final Payment Claim. Thesavings could amount to as much as $3,000,000 per week collectively forthe health care industry for dental PACs and FPCs alone.

An example of a hybrid system of claim processing currently in use willnow be described with reference to FIGS. 1, 2A and 2B.

Referring first to FIG. 1, the U.S. Postal Service, denoted as 100,connects the service provider's office 200 with the insurance company300. It will be appreciated that, since PAC form handling is entirelymanual at location 200, the service provider's office is depicted aslacking computer equipment. In contrast, the insurance company typicallyhas at least one mainframe computer 350 to which terminals 351, 352 onthe respective reviewing dentist's desk 360 and claims adjuster's desk370 are connected. It should also be noted that the mail room 320 ischarged with a variety of tasks associated with the incoming andoutgoing correspondence, as discussed in greater detail below.

As will be appreciated from FIG. 1, a paper PAC form is filled out bythe patient and/or the provider and, along with the substantiatingx-ray, is mailed to the patient's insurance company. Upon entering themail room of the insurance company, the PAC form is assigned a documentidentification number (DIN) and the data from the PAC form is thenentered into the company's mainframe computer. This same DIN is affixedto the x-ray. The x-ray is then manually delivered to the reviewingdentist.

By using the DIN on the x-ray, the reviewing dentist downloads, from themainframe computer, the textual part of the patient's PAC application.The dentist makes a decision, records it in the memory of the mainframecomputer, and has a hard copy of the Predetermination form posted backto the provider. Once the procedure has been completed, the provider'soffice completes the Predetermination form, or fills out a separateFinal Payment Claim (FPC) form. This is then posted to the insurancecompany. A chronological, detailed, step-by-step description of thehybrid system will now be provided with reference to FIGS. 1, 2A and 2B.

During step S1, the dentist decides that a costly procedure is necessaryfor a patient whose insurance carrier requires prior approval for suchtreatment. During step S2, the dentist provides the patient with hisdiagnosis and gives the patient an estimate for performing therecommended procedure. The dentist then asks the patient to contact hisinsurance carrier, or plan administrator at work, to obtain thenecessary PAC form. During step S3, the patient completes that portionof the PAC form that pertains to him, signs the form, and sends it tohis provider.

After the PAC form arrives at the provider's office at step S4, one ofthe office personnel retrieves the patient's file and the PAC form atstep S5, extracts the patient's x-ray, either the original, a copy ofthe original, or a second, previously taken x-ray, during step S6, andthe PAC form is filled out entirely by hand, i.e., the information aboutthe provider has to be entered every time a new PAC form is received,during step S7. Copies of the completed form are made and are placed inthe patient's file during step S8. The envelope containing the PAC formis addressed to the appropriate insurance company at step S9. The formand the x-rays are placed in the envelope during step S10. An entry ismade in both the patient's computer file (if the provider's office isequipped with one) and his hard copy file indicating that the PAC formhas been sent during step S11 and, finally, during step S12, theenvelope is mailed. See task T1 in FIG. 1.

The envelope meanders through the U.S. Postal Service 100 for severaldays at step S113 until the envelope finally arrives at the mail room320 of the insurance company 300 at step S14. In the mail room, theenvelope is opened (step S15), the data from the PAC form is enteredinto the insurance company's mainframe computer 350 and is given aDocument Identification Number (DIN) that identifies the patient and thecurrent claim application (step S16). See task T2 in FIG. 1. During stepS17, the x-ray is labeled with the same DIN. It will be appreciated thatthe DIN on the x-ray and in the document now on the mainframe computermust be identical. It will also be appreciated that for some insurancecompanies, this manual processing is contracted to an outside agency,which would require several more steps, which steps will not bedescribed further.

During step S18, the x-ray is manually forwarded to the reviewingdentist's area. See task T3 in FIG. 1. During step S19, the PAC form istransferred to a directory and waits to be read by a reviewing dentist.

During step S20, a group of x-rays arrives from the mail room at thereviewing dentist's area. A film x-ray is pulled out of the waiting pileby the dentist during step S21 and the reviewing dentist then accessesthe “PAC form” directory during step S22 by, for example, reading theDIN from the x-ray and typing the DIN into the computer. The electronicPAC form corresponding to this x-ray is located in memory and downloadedto the reviewing dentist's monitor during step S23.

The procedure requested is read off the terminal monitor and the filmx-ray is reviewed during step S24 and a determination is made duringstep S25. It will be appreciated that a determination refers to eitheran approval or a denial of the request. Assuming that the procedure isapproved, a statement (or explanation) of benefits (EOB) is alsogenerated. For the purposes of this discussion, it will be assumed thatthe procedure is approved; a denial would necessitate a parallel butalternative set of processing steps, which steps will not be furtherdescribed. During step S26, the insurance company's Predeterminationform is filled out either electronically or by hand. For an electronicPredetermination form, the form is saved to the memory of the insurancecompany's mainframe computer during step S27. The x-ray is returned tothe mail room during step S28. See task T4 in FIG. 1.

Following approval, a paper copy of the Predetermination form is madeduring step S29. See task T5 in FIG. 1. An envelope is then addressed tothe referring dentist and the Predetermination form is placed in theenvelope during step S30. During step S31, the corresponding x-ray ismatched with the Predetermination form and, during step S32, thecorresponding x-rays are placed in the envelope. The envelope then goesback into the U.S. Postal System 100 during step S33. See task T6 inFIG. 1.

Some days later, the envelope finally arrives at the dentist's office200 and is opened during step S34. The results are noted in both thepatient's paper file and computer file during step S35, the x-rays arereturned to the patient's paper file at step S36, and the patient isnotified of the approval and a date is set for performing the approvedtreatment during step S37.

The treatment is completed during step S38 and the Final Payment Claim(FPC) form is filled out during step S39. It will be appreciated thatthe Final Payment Claim form, for many but not all insurance companies,is merely a subsection of the Predetermination form generated in stepS29 (See the paper denoted P* in FIG. 1.); alternatively, the FinalPayment Claim form could be yet another form supplied by the insurancecompany.

The Final Payment Claim form is then sent back to the insurance companywith a copy of the signed Predetermination form during step S40. Seetask T7 in FIG. 1. The Final Payment Claim form enters the mail room asa paper form and the final processing begins during step S41. It will beappreciated that the processing of the Final Claim Form typicallyrequires making several entries in the information stored on themainframe computer 350 and may require the preparation of one or moreforms needed to authorize payment of the final claim. However, since anattachment is not normally associated with the Final Claim Form,additional discussion regarding disposition of the Final Claim Formwithin the insurance company will not be provided.

Thus, the hybrid system under discussion is one that starts in theprovider's office when a patient is told that a PAC form is needed andcontinues until the procedure has been completed and a Final PaymentClaim form has been submitted to the insurance company for payment. Itwill be appreciated that a myriad of problems and inefficiencies arisedue to claim processing in accordance with the hybrid system. Theprincipal problems are as follows:

1. All information needed to complete the PAC form has to be entered byhand. Moreover, all of the information on the PAC form is also manuallytranscribed in order to transfer the information from paper to theinsurance company's mainframe computer. Both of these manual data entryprocess steps are time consuming, very costly, and prone to human error;

2. The x-ray film and the text form are put together and then separatedseveral times during the overall claim processing;

3. The hybrid system requires that a hard copy of the x-ray be sent tothe insurance company. Generally, this x-ray is returned to theprovider. Moreover, the requirement that the dentist provide the x-raytypically means that a duplicate x-ray has to be made by the dentist,which increases the dentist's cost for the service. Oftentimes, theduplicate x-ray is of poor quality and cannot be read;

4. Because prior approval claim forms cannot be processedelectronically, and because PAC forms make up half of all the claimsthat approximately 20,000 oral surgeons, periodontists, andorthodontists make each year, these 20,000 providers have no compellingreason to initiate electronic claims or Final Payment Claims;

5. The document identification number is affixed to the x-ray and theelectronic text in two different processes, one physical and the otherelectronic. This leads to errors;

6. After the procedure has been completed, almost identical informationmay again have to be entered by hand in order to prepare the FinalPayment Claim form;

7. While direct digital x-ray equipment is available, it is difficult tointegrate a digital x-ray into the current hybrid claims processingsystem, i.e., these computerized images would first have to betransferred to film, which would, of course, negate the major advantagefor using direct digital x-rays;

8. Some insurance companies would like to require that x-rays accompanyall dental claims; they are prevented from doing so because of the highadministrative overhead associated with handling hardcopy claims;

9. The patient has to obtain the PAC form from the insurance company orhis employer. In either case, this causes the patient time, is anirritant, and imposes unnecessary delays on the delivery of medical careto the insured;

10. With the hybrid system, no pre-screening of the PAC form for errorsis performed before the PAC form goes to the insurance company; and

11. Provider information, i.e., the dentist's information, often has tobe entered separately on each new PAC form that is submitted.

In short, the current method for handling PAC applications is a hybridsystem somewhere between a Stage 1, a totally paper-based manualprocessing system, and a Stage 2 internally computerized insurancecompany processing system. It is part electronic and part hard copy.Also, each form must be handled twice, once as a hard copy and once asan electronic copy. This is the source of a great many of the abovedescribed problems. Moreover, the current hybrid method is costly. Theprocess starting at the provider's office, continuing through theinsurance company and finally to the return of the Predetermination formto the provider has been estimated to cost $25. Furthermore, the wholeprocess is filled with potential for error, frustration, wasted time andmoney.

The workflow for the filing and processing of a PAC form was describedabove with respect to the dental health insurance which was used, by wayof example, to illustrate the circuitous process involved when a hardcopy attachment is present. Other types of claims, or attachments, ordifferent insurance companies might require slightly different steps.For example, instead of returning an attachment, as describe above, theattachment might need to be microfilmed and archived, or some of theinformation contained in the attachment itself might need to be enteredinto the mainframe. Regardless of these differences, there aresimilarities in the problems that arise in processing such claims.

In summary, in the insurance industry, payers and providers exchange agreat amount of information, which, in general, falls into twocategories:

1. Information flowing from the Payer to the Provider. It will beappreciated that this information can be further subdivided intoadditional types of information including, but not limited toinformation directly related to the Claim Application, e.g., content ofthe claim form or list of specified attachments needed to support aparticular CPT code, general information, e.g., Preferred Provider Listfor specialists, etc., and responses to submitted claims, e.g., RFI on aclaim sent.

2. Information flowing from the Provided to the Payer. It will beappreciated that this information will generally be limited to CompletedClaim Applications, e.g., AIC forms.

It will be appreciated that the information specified by the payer asitem (1) determines the information provided by the provider in item(2). It will also be appreciated that this information flow is furthercomplicated by the fact that each of the various payers may have:

1. Differing Claims Information Requirements, i.e., the information eachpayer requires is unique to that specific payer;

2. Differing General Information, i.e., each payer has a respectiveunique set of preferred providers;

3. Dynamic Information Demands, i.e., the information identifiedimmediately above changes over time; and

4. Different legacy system requirements, i.e., the provider generates aplurality of AIC forms, each going to a different payer in a payerspecified format.

As discussed above, the information flowing from the provider to thepayer can be in one of several forms, including:

1. Paper Claim Forms—These forms tend to have different content and tohave the blanks for content arranged differently on the page. This leadsto confusion and wasted time at the provider's office in completing theforms.

2. Electronic Claim Forms—Because of the differing legacy computersystems and because of the confusion created by different forms, thecurrent electronic solution takes the form of a rigid standardizedelectronic form based on truncated information. Stated another way, inorder to optimize the cost savings of electronic forms, the payers arebound together in a rigid group where all must accept the limitedinformation of a standardized electronic form and none can actindependently to request more information be sent electronically.

3. General Information—Information regarding preferred providers, etc.,is currently available in hardcopy form. It will be appreciated that onehardcopy Preferred Provider List is very time consuming to use; theproblem is exacerbated when many Preferred Provider Lists must bemaintained. Even when this information is in digital form, there arestill problems for providers because each payer has its own database andways of searching for information within that database.

What is needed is an electronic claim form instantiated by a StandardUser Interface (SUI) which allows each provider to complete and thenelectronically transmit claim forms, which differ from one payer toanother, to all payers. What is also needed is a dynamic claim formwhich permits each payer the freedom to independently determine theinformation content of its electronic claim form and to change thatinformation, at will, over time. It will be appreciated that this latterrequirement could be provide while, at the same time, maintaining thesingle multi-payer solution including the SUI. Thus, each payer canspecify and later modify the information that it wants from allproviders, while each of the providers always see and fill in the sameform. What is also needed is a dynamic claim form which allows anindividual payer to be readily selected by the provider. It would alsobe desirable if the dynamic claim form could assist the provider indetermining the information required by the selected payer. It will beappreciated that the enumerated desirable characteristics permitsoverall system coherence (interoperability) yet independence for eachpayer.

SUMMARY OF THE INVENTION

One purpose of the present invention is to create a coherent system thatallows for the electronic filing, transmission, and processing of“insurance claims with attachments,” and to thereby overcome the manydeficiencies of the hybrid system claims processing methodologydescribed above.

Thus, one object according to the present invention is to provide a PACform processing system which minimizes the necessity of manual dataentry. According to one aspect of the present invention, only about 40%of the information needed to complete the PAC form has to be entered byhand. According to another aspect of the present invention, the amountof information that has to be manually re-entered by an operator isessentially zero.

Another object according to the present invention is to provide a PACapplication processing system which eliminates handling errors resultingin a mismatch between, for example, a PAC form and an associated patientx-ray. According to another aspect of the invention, mismatch errors arevirtually eliminated since the electronic x-ray and the associated textare never separated; field data included in for example, the PAC form iscopied and transferred between the server and the mainframe computersystems inside the insurance company. According to yet another aspect ofthe invention, mismatch errors are virtually eliminated since no hardcopy of the x-ray is ever sent to the insurance carrier.

Still another object according to the present invention is to provide aPAC application processing system which increases the number of serviceproviders employing electronic claims systems to thereby reduce theoverall claims processing costs. Since a PAC form can now be handledelectronically in accordance with the present invention, electronicfinal payment claims become viable for approximately 20,000 additionaldentists.

A still further object according to the present invention is to providea PAC application processing system in which Document IdentificationNumbers, or some other method of uniquely specifying the PAC, aresimultaneously associated with both the text and the x-ray by a singlecomputer entry.

Yet another object according to the present invention is to provide aPAC application processing system which operates at lower cost. Costefficiencies are readily achieved according to the present invention byeliminating the need to send a physical x-ray with the claim.

Another object according to the present invention is to provide a costeffective claim processing system wherein little or no information oneither the PAC form or the Predetermination form has to be manuallyre-entered.

Still another object according to the present invention is to provide atotally digital PAC application processing system which can accommodateboth text and digitized x-rays at low cost, thereby allowing insurancecompanies to require x-rays with all claims because such requirementswill not significantly increase the processing cost associated withnon-x-ray documented claims.

An additional object according to the present invention is to provide atotally digital PAC application processing system in which a dynamicclaim form, i.e., the PAC form, which addresses the needs of allinsurance carriers, is stored in the memory of the computer in everyservice provider's office. Alternatively, this form could also be storedand accessed at an Internet website. This, in combination with anon-clearinghouse communications channel and having AIC system softwareat all of the insurance carriers, then eliminates the need for imposingindustry-wide standards, such as ANSI ASC X12, for claim-relatedelectronic transactions. The present invention allows each individualinsurance company to obtain the information that it requires and to getthat information in whatever format that insurance company prefers.Moreover, the ability to transmit the dynamic claim form and integratedattachment to an insurance carrier via a non-clearing housecommunications channel advantageously permits the transmission of othertypes of claims, including worker's compensation claims, to theinsurance carrier. In addition, it will eliminate the irritant of thepatient or provider having to obtain a PAC form from a particularinsurance company. Finally, it will give the provider “time of servicenotification” of the needs of the payer. This, in turn, will drasticallyreduce the rate of claim rejection by the payer with the attendantnecessity of re-review of a claim by the provider.

Another object according to the present invention is to provide atotally digital PAC application processing system in which pre-screeningof information entered into a PAC form, which is stored in the memory ofthe computer in the service provider's office, is easily performed.

Yet another object according to the present invention is to provide atotally digital PAC application processing system in which providerinformation is automatically entered into each PAC form.

It will be appreciated that none of the above-identified objects needactually be present in invention defined by the appended claims. Inother words, only certain, and not all, objects of the invention havebeen specifically described above. Numerous other objects advantageouslymay be provided by the invention, as defined in the appended claims,without departing from the spirit and scope of the invention.

These and other objects, features and advantages according to thepresent invention are provided by a standard graphical user interface(GUI) instantiated by computer software for generating a file from textdata entered into selected ones of N fields in the GUI, wherein theselected ones of the N fields which accept text data are determinedresponsive to text entered into a first predetermined one of the Nfields, and wherein N is an integer greater than 2. Moreover, theselected ones of the N fields is further limited responsive to textentry into a second predetermined one of the N fields. In an exemplarycase, the first predetermined one of the N fields accepts a payer namewhile the second predetermined one of the N fields accepts a CPT code.

According to another aspect, the present invention provides combinationof storage media storing computer readable instructions for permittingnon-networked computers to cooperate synergistically including a firststorage medium storing computer readable instructions for permitting afirst computer system to generate a form including N fields, to receivetextual data as field data in selected ones of the N fields, to assemblethe field data and a corresponding digitized attachment into a firstfile, and to transmit the first file to a second computer system via acommunications channel, a second storage medium storing computerreadable instructions for permitting the second computer system toreceive the first file via the communications channel, to display thecorresponding digitized attachment on a second screen of the secondcomputer system, and to transfer the field data to a third computeroperatively connected to the second computer, and a third storage mediumstoring computer readable instructions for permitting the third computersystem to receive the field data from the second computer, to displaythe field data on a third screen of the third computer system and togenerate a second file including portions of the field data extractedfrom the first file. Preferably, the selected ones of the N fieldsaccepts text data are determined responsive to text entered into a firstpredetermined one of the N fields, and N is an integer greater than 2.

According to yet another aspect, the present invention provides a methodfor operating a computer system including first, second and thirdcomputers, each of the first, second and third computers including amemory, an input device, and a display, respectively, the first and thesecond computers being connected to one another by modems and a commoncommunication line, and the first computer including a digitizingdevice. The method advantageously includes steps for:

(a) retrieving a first form including N fields from storage in the firstcomputer's memory and displaying the first form on the first computer'sdisplay;

(b) selecting M of the N fields responsive to text entry into a firstpredetermined of the N fields;

(c) writing first field data to the first form using the firstcomputer's input device;

(d) digitizing a patient's x-ray to thereby generate a digitized x-ray;

(e) combining the digitized x-ray and the first form so as to generatean attachment integrated file;

(f) transmitting the attachment integrated file to the second computer;

(g) transmitting the first field data from the second computer to thethird computer;

(h) generating a second form upon receipt of the attachment integratedfile, the first and second forms containing at least a portion of thefirst field data;

(i) displaying the first form, the second form and an imagecorresponding to the digitized x-ray on respective displays of the thirdcomputer and the second computer;

(j) writing second field data to the second form using the thirdcomputer's input device;

(k) transmitting the first and second field data corresponding to secondform back to the first computer,

wherein M and N are both integers greater than 2.

According to a still further aspect, the present invention provides acombination of storage media which store computer readable instructionsfor permitting M×(N×R) non-networked computers to form a coherentsystem, including M first storage medium storing computer readableinstructions for permitting each of M first computer systems to receivetextual data as field data, to assemble the field data and acorresponding digitized attachment into a first file and to transmit thefirst file to a selected second computer system and a selected thirdcomputer system via at least one communications channel, N secondstorage medium storing computer readable instructions for permitting theselected second computer system of N second computer systems to receivethe first file via the at least one communications channel, and todisplay the corresponding digitized attachment on a second screen of theselected second computer system, and R third storage medium storingcomputer readable instructions for permitting the selected thirdcomputer system of R third computer systems to receive the field data ofthe first file via the at least one communications channel, and todisplay the field data on a third screen of the selected third computersystem. Preferably, M, N, and R are each a positive integer greater thanone, the selected second computer system and the selected third computerare selected by one of the M first computer systems responsive toaddress information included in the field data in the first file, andmultiple items in the field data is selected by diagnostic code includedin the field data.

According to another aspect, the present invention encompasses agraphical user interface (GUI) instantiated by computer software forgenerating a file transmittable to a selected one of M recipients fromtext data entered into selected ones of N fields in the GUI, wherein theselected ones of the N fields which accept text data are determinedresponsive to text entered into a first predetermined one of the Nfields, the computer software is updated as the respective filerequirements of the M recipients change, and N is an integer greaterthan 2.

According to a further aspect, the invention provides a graphical userinterface (GUI) instantiated by computer software for generating a filetransmittable to a selected one of M recipients from text data enteredinto selected ones of N fields in the GUI, wherein the selected ones ofthe N fields which accept text data are determined responsive to textentered into a first predetermined one of the N fields, the format ofthe file is determined responsive to text entered in the firstpredetermined one of the N fields, and N is an integer greater than 2.

According to a still further aspect, the present invention encompasses acoherent computer system providing interoperability between a pluralityof independent computers. Preferably, the computer system includes aplurality of first computers, each of the first computers comprising afirst storage medium storing computer readable instructions forpermitting the respective first computer to:

generate a form including N fields;

receive textual data as field data in selected ones of the N fields;

assemble said field data into a first file; and

transmit the first file to a selected one of a plurality of secondcomputers via a communications channel; and

the second computers, each of the second computers comprising a secondstorage medium storing computer readable instructions for permitting therespective second computer to:

receive said first file via the communications channel, and

display said field data on a screen of the respective second computer.

Advantageously, in the coherent computer system, the selected ones ofthe N fields which accept text data are determined responsive to textentered into a first predetermined one of the N fields,

the selected one of the respective second computers is selectedresponsive to the text entered into the first predetermined one of the Nfields, the computer readable instructions stored on the first computersare updated responsive to changes to the selected ones of the N fieldsgenerated by a respective one of the second computers, and N is aninteger greater than 2.

According to yet another aspect, the present invention provides anelectronic claim form instantiated by a Graphical User Interface (GUI)which permits each of a plurality of first users to complete and thenelectronically transmit N forms to N respective second users, whereineach of the N forms differs from the remaining N forms in terms of oneof content and format.

According to still another aspect, the present invention provides adynamic electronic form which permits each of a plurality of first usersto: independently determine the information content of its respectiveelectronic form, and freely change the information over time.Preferably, the electronic form presented to each of a plurality ofsecond users is constant, irrespective of changes to the informationcontent dictated by a respective one of the first users.

According to another aspect, the present invention provides a dynamicelectronic form accessible via a computer which provides a first userwith the ability to freely select a second user from a plurality ofsecond users, and which assists the first user in determining,assembling, and transmitting information specifically required by thesecond user, wherein the dynamic electronic form maintains a constantappearance irrespective of changes to required information establishedby any of the second users.

These and other objects, features and advantages of the invention aredisclosed in or will be apparent from the following description ofpreferred embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

The preferred embodiments are described with reference to the drawingsin which like elements are denoted by like or similar numbers and inwhich:

FIG. 1 is a combination high level block diagram and flow diagram whichis useful in understanding the operation and attendant problems of thecurrent hybrid system for Prior Approval Claim form processing;

FIGS. 2A and 2B collectively form a flow chart which illustrates ingreater detail the steps needed to implement the hybrid system of FIG.1;

FIG. 3 is a combination high level block diagram and flow diagram whichis useful in understanding the operation and system of Prior ApprovalClaim form processing according to a preferred embodiment of the presentinvention;

FIG. 4 is a detailed flow chart of the operational steps needed tooperate the system illustrated in FIG. 3;

FIGS. 5A and 5B illustrate alternative embodiments of the attachmentintegrated claim application according to two of the preferredembodiments of the present invention; and

FIGS. 6A and 6B illustrate clearinghouse and non-clearinghouse networks,respectively, connecting service providers and insurance companies.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention is a system and corresponding method implementedby software loaded onto the system for processing textual messages whichare integrated with one or more attachments. Heretofore, suchattachments could not be readily and/or usefully incorporated with thetextual message. Hereinafter, the term Attachment Integrated Claim (AIC)Application will be used to denote a claim application including a textportion and a digital attachment portion. An exemplary embodiment of thepresent invention combines a patient's digitized x-rays with anelectronic insurance claim form to create an electronic Prior ApprovalClaim (PAC) Application. Another preferred embodiment of the presentinvention is a coherent industry-wide system for the electronic filingand processing of these PAC Applications.

It should be noted that the term “digital attachment” as usedhereinafter is not limited to a digitized image or x-ray. The term“digital attachment” is understood to embrace x-rays, CTS, MIS, EKG orEEG recordings, i.e., strip charts, digitized video signals such asMoving Picture Experts Group (MPEG) compressed video signals,transcriptions of Operating Room Notes, estimates for repairs to a houseor car, Explanation of Benefits (EOB), additional ASCII text, and thelike. Moreover, all particulars regarding a specific “attachment,” suchas medical specialty, acquiring modality, the patient's problem, etc.,are to be ignored, since such details have absolutely no bearing on thevarious embodiments of the present invention. The only requirementsregarding digital attachments are that the information must be somethingthat can be digitized, i.e., put into the form of a computer file, andthat once in this form, it can be “read, reviewed or interpreted” by theperson or organization receiving it.

The preferred embodiments according to the present invention will now bedescribed with reference to FIGS. 3 and 4. In particular, as shown inFIG. 3, the overall system according to the present invention includesthe computer components 200 located in the health care provider's officeand the computer components 300 located on the premises of the insurancecompany. Infrastructure 400, which advantageously may be an existingon-line service company, is preferably used in the exemplary embodimentof the present invention to facilitate communication between thecomponents 200 in the service provider's office and the components 300at the insurance company. Preferably, components 500, which are locatedat a value-added service company, permit services ordered by the serviceprovider, patient, or insurance company to be performed. It should benoted that the components 500 may duplicate a subset of the components300 found at the insurance company and, for that reason, description ofthe components 300 alone will be provided below.

It should also be mentioned that the description which follows describesthe invention as it is used in connection with dental insurance forms.However, the present invention is not limited to systems for theprocessing of dental insurance claims. Rather, the present inventionencompasses the preparation, transmission and processing of datapackages including a plurality of data fields wherein at least one ofthe data fields is a digital attachment, e.g., a digital image. Forexample, casualty insurance claims with supporting documentation, i.e.,pictures taken with a digital camera, are within the scope of thepresent invention. In short, the present invention is advantageous invirtually all types of electronic data interchange (EDI) transactions.

As shown in FIG. 3, the components 200 include a personal computer 210including a screen 212, a keyboard 214 and a modem 216, connected to ascanner 220, a printer 230 and an archiving device 240, e.g. a largememory for storage of digital information. Device 240 advantageously maybe a writeable compact disc read only memory (CD-ROM), i.e., a so-calledwrite once-read many (WORM) device, a hard disk drive, a tape back updevice or a removable hard disk device. It should be recognized that thecomputer 210 advantageously can be a computer system including a centralprocessing unit, a graphic display processor, the graphic display device212, and several memories including both solid state memories and a harddisk drive. It should also be noted that the archive device 240 and oneof the memories associated with computer 210 may be the same memorydevice.

Components 300 located at the insurance company include the previouslydescribed mainframe or legacy computer 350 and associated terminals 351,352. In addition, a buffer computer 310, which may be a network server,includes a modem 316 and is connected to a printer 330 and a storagedevice 340. The printer 320 may provide copies of documents directly tothe mailroom 320. Preferably, the computer 310 is connected to personalcomputers or work station terminals 311, 312 via a local area network(LAN) 313. The buffer computer 310 and the mainframe computer 350 areelectronically connected to one another. The details of such aconnection are well known to one of ordinary skill in the art and willnot be described in greater detail.

Before presenting a detailed description of other preferred embodimentsaccording to the present invention, a brief overview of the operatingmethod steps associated with formation, transmission and processing ofthe PAC Application will now be presented. In an exemplary andnon-limiting case, the essential steps of the operating method include afirst subroutine for completing and transmitting needed information to adesignated insurance company. This subroutine includes steps for:

(1) Retrieving the electronic PAC form, e.g., the dynamic claim form(DCF), from storage in the computer's memory (or, in another exemplarycase, from a website) and displaying the PAC form on the computerscreen;

(2) Filling out of PAC form on the computer screen;

(3) Digitizing, e.g., scanning, the patient's x-ray;

(4) Combining the digitized x-ray and the electronic PAC form into thepatient's PAC application; and

(5) Transmitting the patient's PAC application to the designatedinsurance company.

After the PAC application is received by the insurance company, theinsurance company performs another subroutine, which includes steps for:

(6) Reviewing the PAC application;

(7) Generating an electronic Predetermination form when the applicationhas been reviewed; and

(8) Transmitting the electronic Predetermination form back to theinsured's Service Provider.

When the electronic Predetermination form from the insurance company isreceived by the service provider, an additional subroutine is performedby the service provider. This subroutine advantageously includes stepsfor:

(9) Reading the electronic Predetermination form;

(10) When the approved procedure has been performed, adding completiondata to the electronic Predetermination form; and

(11) Transmitting the annotated electronic Predetermination form back tothe Insurance Company.

When the annotated electronic Predetermination form is received from theservice provider, the insurance company performs a final subroutine,which includes steps for:

(12) Reviewing the annotated information; and

(13) Issuing the final payment to the service provider.

The method for operating the system according to a preferred embodimentof the present invention will now be described in detail.

The method starts at step S101 with the service provider's diagnosisthat a costly procedure is necessary. It is then determined that thepatient needs prior approval from his insurance company. During stepS102, the patient is provided with an explanation of the procedure and acost estimate for that procedure. The service provider and the patientthen prepare the needed PAC Application.

During step S103, a member of the service provider's office staffaccesses the Attachment Integrated Claims (AIC) software stored innon-volatile memory on the service provider's computer system 210, whichsoftware advantageously is Graphic User Interface (GUI) software.Preferably, this AIC software is written in C++, Visual Basic, or someother appropriate graphical programming language.

It will be appreciated that commercial software packages, such as LOTUSNOTES™, have been designed with the capability of addressingcombinations of text and graphics files. However, the purpose of thesepackages is to create an “environment” or “platform” in which specificapplications can be developed. In contrast, the preferred embodimentsaccording to the present invention are directed at providing integratedtext and graphics files within a coherent system and methodology foraddressing the specific needs of the work flow, preferably of aparticular industry. That is, it is a particular application. It ispossible, but not necessary, that the software needed to implement thepreferred embodiments of the present invention can be developed withinthe frame work of the environment created by something such as LOTUSNOTES™. Alternatively, the software needed to implement the preferredembodiments of the present invention can be developed using either JAVA™applets or standard graphics markup language (SGML).

Contained within the AIC software are PAC forms for insurance companiesusing the AIC system. When one of these is opened it acts as a templateupon which a new computer file will be based. This computer file willultimately contain the patient's PAC Application.

It will be appreciated that the PAC form when displayed on thecomputer's screen 212 contains boxes, such as those depicted in FIGS. 5Aand 5B, in which alpha-numeric characters can be entered so that, whenthe characters are entered in these boxes they are entered so as to filla “field,” a delimited alpha-numeric character string. Being a “field,”the information denoted by the characters can be transferred to and usedin completing other fields in related documents. Also, the informationitself, or lack thereof, can be used as a logic control device, e.g.,used to remind the preparer that critical information has not beenentered.

In the exemplary case being discussed, the PAC forms of many insurancecompanies have been encoded and stored in memory on the serviceprovider's computer system 210. This can be advantageously done in thefollowing way. The PAC forms for all the insurance companies using theAIC System are gathered. Then a union of all the information requestedin these PAC forms is made. A field is created for each element ofinformation requested. For example, Field #1 contains the patient'sfirst name, Field #2 contains the patient's last name, and so on. Thisis done until the “information fields” of the PAC forms for all of theinsurance companies are included.

In order to increase the efficiency of the clerical staff at theprovider's office, it is desirable to give them basically the same formto fill out every time, i.e., information is always in the same place onthe form. To do this a template is created. What actually appears on thescreen of the preparer is always the same. What changes is that anygiven insurance company will desire only a particular subset of thetotal number of fields. So if insurance company A is chosen, then fields1,2,3,7,9 . . . have to be filled in, whereas, if insurance company B ischosen, then fields 2,3,4,5,7,11, . . . have to be filled in. The fieldsnot needed are automatically signified in some way by the AIC software,e.g., if insurance company A does not need Field #4 then that block onthe screen is gray and can't be typed into (i.e., is “write protected”).Thus a “customized claim form” is provided for every insurance companybased on a single, universal compilation of fields. As described below,what allows this method to work is that there is AIC software at theinsurance company that has been coordinated with the AIC software at theproviders office.

The AIC Software GUI asks for the name of the insurance company, whichcan be typed in or selected from a directory. Once the insurance companyhas been identified, the fields needed to complete the insurancecompany's PAC form are displayed on the screen 212 of the serviceprovider's computer system 210. The AIC software advantageously canautomatically fill in all the parts of the form that are specific to theservice provider, e.g., name, address, Provider Identification Number(PIN), etc. It is estimated that this alone eliminates 20% of the workneeded to fill out the PAC form. An electronic signature couldadvantageously be added at this time for the service provider or couldbe added as part of the final review and approval before the completedPAC application is transmitted.

Needed patient information is then entered into the PAC form on thecomputer screen 212, preferably while the patient is still in theoffice, and a provider Document Identification Number (PDIN) can be usedto label the form, if so desired. This is now a computer file identifiedas referring to the patient. It should be noted that some form ofsignature can be provided in the appropriate field. As an example, aspecial electronic pad and pen can be used such that when the patientsigns on the pad his signature is affixed to the electronic PAC form.

It will be appreciated that, for example, the patient identificationnumber (patient ID) from the service providers own data baseadvantageously can be used to access patient specific information thatthe AIC software can insert into the PAC form, i.e., the DCF. Moreover,it will also be appreciated that the CPT code for a procedure could bekeyed in to further differentiate the DCF. For example, if the CPT codeis associated with the requirement for an X-ray by a particular payer,the DCF will identify the need for an X-ray attachment to the serviceprovider. Moreover, the CPT code advantageously can be employed tofurther differentiate the DCF to, by way of a non-limiting example,provide a list of Preferred Providers that the particular payer haspre-approved for service providers wishing or needing to refer the CPTcode-identified procedure to a specialist.

During step S104, the patient's x-ray is digitized. In an exemplarycase, there is a scanner 220, i.e., digitizer, connected to the serviceprovider's computer system running the AIC software. The patient's x-rayis scanned and converted into a series of ordered numbers (i.e., a bitmap of the x-ray image) and stored. It should be noted that these storedseries of numbers can be reconstructed by the computer system to displaythe x-ray on a computer monitor, i.e., the bit map can be used toreconstruct a raster image of the x-ray for display.

It will be appreciated that the AIC software advantageously can bewritten to minimize the time needed to scan the x-ray. In an exemplarycase, the operator can specify the type of x-ray or x-rays that arebeing scanned. This is done so that blank areas are not being digitizedand added to the patient's file. It will be noted that this will alsosave on transmission time to the insurance company. Further, as will bereadily appreciated by those skilled in the art, the text and image datacomprising the file can be encoded and compressed in any manner wellknown in the art in order to minimize data storage and transmittingclaimed requirements.

It should also be mentioned that steps S103 and S104 need not beperformed in any particular order. In an exemplary case, the patient'sx-ray may be digitized before the PAC form is called up on the computerscreen 212 and completed.

During step S105, the PAC application is formed from the electronic PACform and the digitized patient's x-ray. It should be noted that thepresent invention is not limited to a particular format for the PACapplication. For example, the format of the PAC applicationadvantageously may consist of a text file and an associated digitizedimage file. It should be noted that in one case the text and image fileswill be transmitted seriatim. For that reason, the text file (i.e., thePAC form) and the image file (i.e., the digitized x-ray) must crossreference one another (i.e., be correlated) so that these files can becontinuously associated with one another after transmission to theinsurance company. If the attachment is simply additional ASCII text,e.g., Operating Room Notes, then the only step necessary is to transferthe additional ASCII text into the integrated file format. Once in theintegrated file format, all processing is the same as if the filecontained an image attachment.

In an alternative exemplary case, the PAC application advantageously canbe prepared according to the Graphic Interchange Format8 (GIF)specification, which specification is the intellectual property ofCompuServe Incorporated. In order to form the PAC application, thedigitized x-ray is converted to a GIF image file. It will be appreciatedthat the GIF image file advantageously can include one or more blocks oftextual data denoted by a comment extension, as described in Version 89aof the GRAPHICS INTERCHANGE FORMAT documentation published byCompuServe, Inc. It should be noted that since the textual informationcorresponding to the data needed to complete the PAC form is included inthe GIF image file comments, the possibility of file separation andconsequent mishandling or mismatching of the separate components of thePAC application is virtually eliminated. Alternatively, the TIFFstandard format advantageously can also be used to co-join field anddigital image data.

It will also be appreciated that the concept of embedding comments intothe GIF or TIFF image file format is a standard practice employed bythose of ordinary skill in the art of graphic image preparation, e.g.,by photographers and digital artists who wish to identify their works.However, it should also be noted that the use of a comment block storingdata fields used in reconstructing a completed form, e.g., a completedPAC form, has never before been described or suggested. Furthermore,since the technique described above is a novel solution toelectronically forwarding an insurance claim form and an associatedattachment as one, the use of the comment block to store the PAC formfield data is likewise a unique and novel aspect according to thepresent invention.

In yet another alternative exemplary case, the digitized x-ray isautomatically added (inserted) to the electronic form by the serviceprovider's AIC software and forms a single computer file, as depicted inFIG. 5B. It should be noted that the non-text portion of the PACapplication is labeled with the same provider Document IdentificationNumber (DIN) as used on the text portion, i.e., the electronic PAC form.These two objects together now form the patient record, i.e., thepatient's PAC application. The PAC application is now ready to be sentto the insurance company.

During step S106, the service provider's office staff then transmits thecompleted PAC application to the insurance company. For example, whenthe transmission icon of the GUI AIC software running on the serviceprovider's computer system 210 is activated (e.g., “clicked” on), thefollowing subsets are automatically executed:

(a) A check is first performed to ensure that the PAC application hasbeen completely filled out. In the event that problems and/or errors arenoted by the AIC software, the system user is notified of the error byan appropriate annunciator, e.g., the suspect area can be highlightedand a message concerning the problem and/or error could be generated anddisplayed on the monitor;

(b) A hard copy of the PAC application is printed out, if desired, bythe service provider. The hard copy may advantageously be placed in thepatient's permanent file;

(c) Moreover, and more importantly, the completed PAC application isarchived in the service provider's computer system 210, 240. It will beappreciated that this archive copy can be accessed in several ways suchas by patient name, social security number, document identificationnumber, etc. That is, it can be accessed using any of the informationthat has been entered into the PAC form; and

(d) The service provider's computer system establishes a connection withthe on-line service 400 and transmits the patient's PAC application tothe insurance companies e-mail address. See task T1 a of FIG. 3. It willbe appreciated that the e-mail addresses of all the insurance companieshave been stored in the AIC software residing in the memory of computersystem 210. In short, the e-mail address is identified when the name ofthe payer, i.e., the insurance company, is identified in the DCF.Advantageously, the PAC application can be transmitted immediately orcan be scheduled for transmission at a convenient time, i.e., can betransmitted after all of the PAC applications and other forms have beenprepared for the day. Preferably, the AIC software on the serviceprovider's computer system 210 keeps a record of when the PACapplication was sent. In addition, the AIC software maintains and usesthe proper protocols so that when the PAC application reaches theintended insurance company, it arrives there with the alpha-numericportion of computer file intact, i.e., the information is stored infields that can be read by the corresponding AIC software module in thecomputer system 310 at the insurance company.

It should be noted that the specific transmission path taken by the PACapplication from the service provider's computer system 210 to thecomputer system 310 maintained by the insurance company is not anessential limitation of the novel system and corresponding operatingmethod according to a preferred embodiment of the present invention. Theonly requirement of a transmission path is that it maintain the digitalintegrity of the PAC application computer file. Thus, the patient's PACapplication can be sent to the insurance company in several ways usingmodems 216 and 316, including via normal phone service, an on-lineservice, or bulk data transmission lines.

In an alternative exemplary case, the completed PAC applications mayeven be transferred to tape or CD-ROM and then sent through the U.S.Postal Service 100 of FIG. 1 to the insurance company's mailroom 320.For purposes of the discussion which follows, only the exemplary case inwhich the PAC application is transmitted via the on-line service 400 isdescribed in any detail.

One of the beneficial aspects of the present invention is provided bythe combination of the dynamic claim form on the service provider'scomputer 210 and the use of any non-restrictive communications channel,i.e., the insurance companies are able to freely modify informationrequirements demanded of the service providers. Existing electronicclaims processing systems, such as NEIC, are based on a clearinghouseconcept, as illustrated in FIG. 6A. In a clearing house system, allclaims enter the clearinghouse computer(s), are manipulated, and thenare transmitted to the appropriate insurance company. One consequence ofthe clearinghouse architecture is that it puts a constraint on theinsurance company to use a standardized claim form. The individualinsurance companies have little or no control of the information contentin the form. Moreover, because the claim form is standardized, changesare very difficult to make, i.e., any change requires that all memberinsurance companies make the change together.

In contrast, placing AIC software packages in the providers' offices andin the insurance company processing centers, [these packages arecoordinated with one another, but not identical to one another], allowsevery payer to transmit claim form updates to every provider. In theprovider's office, the change would be reflected primarily in changes tothe number of fields needing information and, rarely, in the addition ofa new field to be completed by the provider. It will be appreciated thatthe AIC software could check for updates, and download any updatelocated, during the PAC transmission described in detail elsewhere inthis specification. Alternatively, all payer-specific updates to the DCFcould be centralized on a single server, so that the service providerscould check for all updates from all payers whenever the serviceprovider transmits a completed DCF to any single payer. Moreover, theblank DCF templates advantageously could be accessed at an Internetwebsite for either downloading or completion by the providers.

As illustrated in FIG. 6B, the interchange between the provider's officeand the insurance company(ies) advantageously can be performed using anonline service or Internet Service Provider (ISP), providing that theservice provider permits 8-bit file interchanges. In that case, theupdate information could be transmitted to the provider when theprovider dials into the online service. Thus, while it is true thattransmission accomplished using e-mail involves an intermediarycomputer, the online service merely provides a mail box and places noconditions on the insurance information contained in the claim itself.

Advantageously, the non-clearinghouse architecture and coordinated AICsoftware package, along with periodic updates, facilitates the provisionof the dynamic claim form. That is, each insurance company can determinethe content of its own claim form. The packages used by the providersare instructed regarding the information content, protocols, etc. eachinsurance company wants its claim to have. It will be appreciated thatthe package at each insurance company is designed to accept only thoseclaims that meet the specifications of the respective insurance company.In addition, if an insurance company wants to change the content of itsclaim form, it can do so independently of the other insurance companies.In summary, the above combination maintains interoperability throughoutthe industry even while it allows information requests to change.

Beneficially, the non-clearinghouse architecture reduces costs, allowsfor the direct digital interchange of data from one insurance company toanother, and permits many different types of forms to be run off thesame system, e.g., commercial insurance claims and workers' compensationclaims can both be processed in the provider's office using the samedynamic claim form. This produces a claims processing system which ismore robust than anything on the market today.

During step S107, the PAC application is pre-processed by thevalue-added service provider 500. For example, the patient's PACapplication can be accessed by the employees of the value-added servicecompany to perform services for either the patient, the serviceprovider, or the insurance company, or any combination thereof. See taskT2 of FIG. 3. These value-added services could include archiving of thepatient's dental x-rays so that all records for a particular patient arecentrally stored, screening of the entire PAC application for errors,compiling statistics on all PAC applications and, in some instances,even performing the review process for the insurance company.

Next, the insurance company accesses the PAC applications at the on-lineservice during step S108. In an exemplary case, each insurance companyhas an E-mail address specifically for the purpose of receiving PACapplications. An insurance company accesses its E-mail box and finds awaiting list of PAC applications which are subsequently downloaded toGUI-capable computer system 310. In a preferred embodiment as shown inFIG. 3, the GUI-capable computer system 310 advantageously is connectedto the claims management mainframe computer 350 of the insurance company300. Preferably, the GUI-capable buffer computer system 310 is apersonal computer (PC) or a PC server which advantageously can beoperated in parallel with but separate from the insurance company'smainframe computer 350; data, however, beneficially can be interchangedbetween the buffer computer system 310 and the mainframe computer 350.In an exemplary case, as the personnel at the insurance company 300apply an insurance company document identification number (DIN) to eachreceived PAC Application, the field data contained therein is copied bythe buffer computer system 310 and transmitted to the mainframe computer350. See task T1 b of FIG. 3.

Alternatively, the entire PAC application advantageously could be copiedby the buffer computer system 310 and downloaded to the mainframecomputer 350, where the image portion of the PAC application then canremoved from the mainframe's memory. This approach employs basically thesame distribution of information, i.e., text form in the mainframe 350and field data and images in the buffer computer system 310.

In an exemplary case, this buffer computer 310 is part of a local areanetwork (LAN) 313, which is connected by high bandwidth cables topersonal computers or other GUI-capable terminals 311, 312 at the desks360 and 370 of the individual reviewing dentists and claims adjusters,respectively. It should be noted that the necessary AIC software hasbeen loaded onto the server 310, the individual personal computers 311,312, and the mainframe 350. Preferably, once the patient's PACapplication has been received, the system's AIC software at either thevalue-added service provider 500 or the insurance company's computer 310automatically notifies the referring service provider that the PACapplication has been received for processing, e.g., using a conventionalE-mail message.

At step S109, the reviewing dentist calls up the graphics portion of thePAC application, in an exemplary case, from the server 310 to a personalcomputer 311, each of which is running the appropriate AIC software, viathe LAN 313 using the assigned DIN. See task T3 in FIG. 3. The reviewingdentist then calls up the text portion of the PAC application from themainframe computer 350 using the terminal 351. See task T4 in FIG. 3. Itwill be appreciated that the sequence can be reversed at the reviewingdentist's option. It should be noted that some small insurance companiesmay not even require server-LAN 310, 313 system discussed above, butjust a single PC that will incorporate the functions of the elements310, 311, 312, and 313. In any event, the reviewing dentist calls up apatient's PAC application using both his personal computer 311 andterminal 351. When this happens, the system AIC software automaticallygenerates the insurance company's Predetermination Form on one of thetwo screens 311, 351. The installed AIC software advantageously canautomatically transfer whatever information from the PAC application tothe Predetermination form that is useful in completing thePredetermination form, e.g., repetitive information/fields. Forinstance, the service provider's Document Identification Number (PDIN)and the Provider Identification Number (PIN) can be transferredautomatically to the Predetermination form. In addition, the AICsoftware can be written to display the information in the PAC form onthe screen 351 in exactly the way that this particular insurance companywants it displayed.

In a alternative implementation, a single monitor on the computer 311supporting multiple windows, at least one of which runs terminalemulation software for displaying the output of the mainframe computer350, could advantageously be used to display both parts of the PACapplication.

With the AIC system described above, the use of “fields,” the dynamicclaim form, and the placing of coordinated AIC software at both theservice provider's office and the insurance company, has eliminated theneed for standardized forms. The result is that each insurance companygets exactly the information it wants and has it displayed in exactlythe way it wants. Thus, the compromise of a standardized claim form asis required with the present NEIC system is avoided.

In an exemplary case, the reviewing dentist is provided with threemonitors or a large graphics-capable monitor having a multi-page displaymode, on which can be displayed the three pages of the patient file. Itwill be appreciated that this configuration is optimized to facilitaterapid review of the PAC application. The reviewing dentist enters anInsurance Company Document Identification Number (DIN) at this point,which number is affixed to all three pages of the patient's file.

During step S110, the reviewing dentist reviews the PAC application.More specifically, the review process consists of a review of themedical facts or evidence (i.e., the text and x-ray information in thePAC application), as well as a review of the patient's insurance policy.Once the reviewing dentist has made his analysis, he goes to thePredetermination form, i.e., the third page, and enters the requiredinformation to either approve or disapprove the procedure during stepS111. The specific details regarding the information provided by thereviewing dentist will depend on the procedures established at eachindividual insurance company. Either the reviewing dentist or anotherperson, e.g., a claims adjuster, will do the review of the patient'sinsurance policy.

Advantageously, there are several ways to gain access to thisinformation. First, the server 310 can have information on every policyholder loaded into its memory. Second, the benefits reviewer, i.e.,either the reviewing dentist or the claims adjuster, can have anothermonitor 351, 352 on his desk that is connected to the company mainframecomputer 350. Thus, all that the benefits reviewer must do is select thepatient's insurance ID number and his benefits sheet will appear. Thebenefits reviewer then reads off the information that must be entered inthe Predetermination form and enters the information into the either theGUI-capable computer system 310/311/312 of the mainframe computer 350during step S111. It should again be noted that there is an electronicconnection, in the preferred embodiment, between the mainframe computer350 and the server 310. Whatever information is deemed necessary by thatparticular insurance company to complete the Predetermination form canbe transferred between the mainframe computer 350 and the buffercomputer system 310 by entering data on one of the terminals 311, 351.See, for example, task T5 in FIG. 3.

At this point, the Predetermination form is ready to be sent to thereferring service provider. When the transmit icon on the computerscreen of the benefit reviewer's GUI-capable computer system 311, forexample, is activated (e.g., by being “clicked” on), the followingsubsteps are automatically performed:

(a) First, a check is performed to verify that the Predetermination formhas been completely and properly filled out. If errors are detected, theAIC software notifies the operator via an appropriate annunciator;

(b) The Predetermination form and the patient's PAC application aredownloaded to the buffer computer 310. See task T5 a. From thisplatform, the company accesses the on-line service 400 and transmits thePredetermination form, i.e., just the information “fields”, to theservice provider's e-mail address, which is stored in the memory ofserver 310. See task T6. In the AIC software, records are kept as towhich PAC applications have been sent and when and to whom. The properprotocols are used so that when the application reaches the serviceprovider, it arrives there as a computer readable file, i.e., theinformation is stored in “fields” that can be read by the AIC softwareat both the insurance company and the service provider's office;

(c) A hard copy of the Predetermination form and x-ray are printed, ifdesired, by the insurance company, see task T7;

(d) The complete patient file is archived in the insurance company'scomputer system 310, 340, if desired. See task T8. Otherwise, just theelectronic Predetermination form and the PAC application are saved; and

(e) The entire three page patient file is now cleared from the reviewingdentist's displays 311, 351 and the AIC software prompts the reviewingdentist as to whether another patient file should be accessed.

During step S112, the service provider accesses his e-mail address withthe on-line service 400. All Predetermination forms which have beenreceived are automatically delivered to the service provider's computersystem 210 for insertion into the appropriate patient file. The serviceprovider then reviews the Predetermination forms. Upon evaluating thedecision of the reviewing dentist, the service provider can eitherperform the procedure (if approved) or discuss the matter with thepatient's insurance company (if not approved).

During step S113, the approved procedure is performed by the serviceprovider. Once the approved procedure has been completed, the serviceprovider preferably sends in the Final Payment Claim (FPC) form. In anexemplary case, this could be as simple as just filling out anothersection of the Predetermination form and signing it using the electronicsignature pen, as discussed above. It should be noted that in FIG. 3,this is labeled as P*. Alternatively, if the insurance company sodesires, a separate form just for this purpose can be employed. Thislatter form, which advantageously is the same dynamic claim formdiscussed above, is stored in the memory of the provider's computer,must have the Insurance Company's DIN for this particular patient'sprocedure and all other needed information transferred to it, whichadvantageously can all be done by the AIC system software at step S114.At step S115, the Final Payment Claim form is transmitted back to theinsurance company. See task T9 of FIG. 3. In an exemplary case,activating the transmit icon on the service provider's computer system210, e.g., by “clicking” on it, automatically results in the executionof the following substeps:

(a) A check is performed to see that the form has been completely andcorrectly filled out. If an error has occurred, the AIC software alertsthe operator of the detected error;

(b) A hard copy of the form is printed out, if desired, by the serviceprovider;

(c) The complete patient's electronic file is archived in the serviceprovider's computer system 210, 240. It will be noted again that thepatient's electronic file can be accessed by patient name, socialsecurity number, document identification number, etc.; and

(d) The computer system 210 establishes a connection with the on-lineservice and transmits the patient's Final Payment Claim (FPC) form tothe insurance company's e-mail address.

As previously discussed, the AIC software on the service provider'scomputer system 210 advantageously may include facilities fortransmitting the Final Payment Claim form to the insurance company at alater time, e.g., for transmitting all of the days PAC application andFPC forms at one time.

It will also be noted, as discussed above, that the AIC softwaremaintains records as to which claim form was sent and when it was sentto the insurance company. In an exemplary case, the E-mail address towhich the Final Payment Claim form is sent is different from the addressused in transmitting the PAC application. Since the Final Payment Claimform does not include a digitized image, i.e., a digitized x-ray, theinsurance company may choose to have the Final Payment Claim formdirected to an E-mail address accessible from the mainframe computer350. If the insurance company's processing protocol requires anindependent review of the PAC application, the Predetermination form andthe Final Payment Claim form before payment can be authorized, theE-mail address advantageously can be accessed from either the server 310or the mainframe computer 350, since these two computer systems areelectrically coupled at the insurance company 300.

The insurance company then receives the Final Payment Claim forms duringstep S116 when it accesses its Final Payment Claim forms mail box. In anexemplary case, the computer system receiving the Final Payment Claimforms is not the claims management mainframe computer 350 of theinsurance company but, rather, it is a personal computer or server 310that is part of a parallel system having an electronic connection to themainframe computer 350. This buffer computer 310 advantageously can bepart of a LAN 313. The buffer computer 310 is connected by highbandwidth cables to the personal computers or GUI-capable terminals 312located at the claims adjusters's desks. See task T10. It should againbe noted that the appropriate AIC software modules have been loaded ontoboth the server 310, the personal computers 312 and the mainframecomputer 350. It will be appreciated that the information entered incomputer 312 advantageously can be automatically transferred to themainframe 350 through the transmission path including the computer 312,the buffer computer 310 and the electronic connection to the mainframecomputer 350.

The Final Payment Claim form is then reviewed during step S117. Theadjuster reviewing the Final Payment Claim form can, if necessary, callup the PAC application from the memory of the server 310, since theoriginal Insurance Company Document Identification Number for thecorresponding PAC application was transferred to the Predeterminationform and, thus, to the Final Payment Claim form. In addition, theadjuster can, if need be, call up the information on the insurancepolicy of the particular patient stored in mainframe computer 350 viaterminal 352. Preferably, the insurance company provides the adjusterwith a separate monitor 352 connected to the claims management mainframecomputer 350.

Whatever internal paperwork is necessary to be filled out isautomatically downloaded with the Final Payment Claim form itself by theappropriate AIC software module. Part of this paperwork will preferablybe form(s) which must be completed so as to order a check issued to theservice provider along with an Explanation of Benefits (EOB). Also atstep S118, whatever information is necessary to be entered into themainframe 350 can be entered directly through the use of the terminal352 or indirectly through computer 312, the buffer computer 310 and theelectronic connection to the mainframe computer 350.

Finally, upon activating the transmit icon on the insurance company'spersonal computer 312, for example, the following substeps areautomatically executed:

(a) A check is again preformed to see that the form has been completelyand correctly completed and the operator is notified if an error hasoccurred;

(b) A hard copy of the form is printed out, if desired by the insurancecompany;

(c) The complete patient file is archived in the insurance company'scomputer system, e.g., on the server. It should again be noted that thepatient file can be accessed using the patient's name, social securitynumber, or an assigned document identification number, etc.; and

(d) A payment draft is issued, in the approved amount, to the serviceprovider. This can be done through any number of methods, includingprinting a hard copy check and forwarding it through the U.S. postalservice, electronic funds transfer, etc. Each form of payment will beaccompanied with the normal description of the service to which thesefunds should be applied, i.e., the EOB (Explanation of Benefits).

The preferred embodiment was described as transmitting digitized dentalx-rays as part of an integrated PAC application file transmitted betweena service provider and an insurance company. However, the presentinvention is broadly directed to the integrated transmission of any“electronic text form” and any “attachment.” Further, the presentinvention is not limited to transmissions between providers andinsurance companies. Rather, it is intended to facilitate thetransmission of electronic forms with attachments between any person ororganization and any other person or organization.

For example, the present invention has utility in such other areas asProperty/Casualty Insurance, law enforcement, and Internet marketplaces.Thus, the “attachment” need not be an x-ray or other type of image.Rather it can be any information which is not easily incorporated intoan associated “electronic text form” and/or cannot be easily displayedon an existing legacy computer system. Attachments can include, but arenot limited to, pictures, graphs, sound recordings, and nonstandardtext. Examples would be x-rays, CTS, MIS, EKG or EEG recordings, i.e.,strip charts, digitized video signals such as Moving Picture ExpertsGroup (MPEG) compressed video signals, transcriptions of Operating RoomNotes, estimates for repairs to a house or car, EOB (Explanation ofBenefits), additional ASCII text, and the like. As used in thisdescription, all particulars regarding a specific “attachment,” such asmedical specialty, acquiring modality, the patient's problem, etc., canbe ignored. These are details having absolutely no bearing on theessence of the present invention. The only requirements are that theinformation must be something that can be digitized and therefore putinto the form of a computer file, and that once in this form, it can be“read, reviewed or interpreted” by the person or organization receivingit.

In addition, it should be noted that the DCF could be usefully employedindependent of the “attachments” problem. The DCF is an electronic form(with specific fields that must be filled out) that adjusts itself, inboth information required and formatting, to meet the demands of thereceiving party. Furthermore, it does this while maintaining a StandardUser Interface. It is particularly advantageous for Electronic DataInterchange (EDI) situations where a user must send similar (but notnecessarily identical) messages to several organizations. This isparticularly important where, once an electronic form is received bythose organizations, the information in the message must be digitallyintegrated into differing information systems.

The exemplary preferred embodiment discussed above addresses only astand-alone system of computers, which is independent of the practicemanagement software in the local dentist's office, the claims managementsoftware at each insurance company, and of clearinghouses such as NEIC.However, it will be appreciated that there is an entire spectrum ofdifferent ways to structure a system which will support “attachmentintegrated claims” which will be readily apparent to a person ofordinary skill in the art (after having the benefit of the presentdisclosure), all of which are encompassed by the present invention.

It should also be noted that the AIC software described thus far hasbeen independent of the service provider's practice management software.However, one alternative preferred embodiment calls for integrating theAIC software with the practice management software. This would furtherreduce the amount of time spent actually filling out the PAC applicationand the other paperwork involved in the overall claims process.

Electronic filing of standard 100% text claims is now being supported bymany practice management systems and by stand-alone electronic claimssoftware systems. In another alternative preferred embodiment, the AICsoftware could be incorporated into these systems as a means of sendingthe x-ray part of the PAC application.

It should also be mentioned that the present invention represents atotal solution on three levels to the problem of streamlining theprocessing of insurance claim forms with attachments. First, the systemfrom provider to third party payer is totally digital. The presentinvention includes an integrated system of hardware and AIC softwarethat allows: (1) providers to create an electronic (digital) version ofa patient's PAC application (text and x-ray); (2) providers to transmitthe PAC application to an insurance company; and (3) the insurancecompany to read the patient's PAC application. Thus, it creates acoherent system for the filing, transmission and processing of “claimswith attachments.”

Secondly, the present invention is an industry-wide system which allowsevery provider to interface with every third party payer. Finally, thepresent invention is a system which permits all communications betweenthe service provider and the insurance company to be totally electronic.The present invention makes the entire process electronic from theinitial preparation of the PAC form to the payment of the final claim.Communication is digital in both directions.

As discussed above, the patient, the service provider, the insurancecompany, or any combination thereof may prefer that all communication beperformed through a value-added service provider 500. The servicesperformed by the value-added service provider 500 advantageously couldinclude any or all of the services listed immediately below.

First, the value-added service provider 500 may act as a National DentalData Bank (NDDB), i.e., a data bank storing patient dental images.Limited information regarding the patient from the PAC form is attachedto the digital x-ray to produce a digitized x-ray record. Thisinformation could include, for example, the date that the x-ray wastaken, the identity of the service provider who took the x-ray, thepatient's name and social security number, etc. The digitized x-rayrecord is archived at NDDB for the patient. This would allow theretrieval of the x-ray by the patient at any time for any reason, e.g.,the patient could ask that the x-ray and claim be sent to anotherdentist for a second opinion and/or for a second price estimate. Infact, the patient may request that the PAC application be sent to otherqualified service providers so that they could competitively bid on theneeded procedure.

In addition to the NDDB function, the value-added service provider 500could perform pre-screening of the PAC applications for errors and couldprovide statistics to both the service providers and the insurancecompanies regarding, for example, the frequency at which a procedure isperformed or the frequency at which follow up treatment is requiredafter a first procedure is performed. The value-added service provider500 could also do the prior approval review for an insurance company orcould provide other services tailored to suit the needs of the serviceprovider, the patient, and/or the individual insurance company.

It should be mentioned that there are three outside areas of softwarethat advantageously can be taken into consideration, or ignored, withthe present invention. These are practice management software run by theservice provider, claims management software run by the insurancecompany, and clearinghouse software. The present invention allows forthe entire spectrum of interfacing, from a totally stand-alone systemfor electronic claims processing to one that is fully integrated withpractice management software, claims management software, and the NEIC.Moreover, the present invention is specifically contrived so that it canbe used simultaneously in all modes. That is, one insurance companycould choose to have no interfacing between the computer 310 running theAIC software and its mainframe computer 350, while, at the same time,another insurance company could choose to have AIC software runningsimultaneously on both the mainframe computer 350 and the buffercomputer system 310. Thus, each operating mode or methodology could beconsidered to be a different preferred embodiment of the presentinvention, notwithstanding the fact that all modes are expected to beoperating simultaneously.

The present invention was motivated by a desire to solve a problem whichhas existed for many years. The AIC software was designed with this inmind. Thus, for example, redundant information is automatically movedfrom one form and file to another along the chain of operating steps,i.e., from one document to another within a given insurance company'sset of forms. Moreover, the AIC software advantageously can be writtenin C++ or some other appropriate programming language. The reason forthis is so that when information in entered into areas of the electronicPAC forms, it is entered as a “field.” Being a “field” it can be used asa logic control device, as discussed in greater detail above.

The overall workflow problem to be addressed is treated as a coherentwhole. Thus, AIC software is specifically designed so that, at each stepof the preferred operating method, the fact that the information is indigital form is used to streamline the process. Thus, the AIC softwareis designed to eliminate inefficiencies and deficiencies that exist incurrent claims handling systems. For example, the information itself canbe used as a logical control device and it can also be transferred fromone document to another. It should be noted that all available forms arewritten into the AIC software so that they are coordinated with oneanother, that is, they know where each has a similar “field.”

It should also be noted that the AIC software automates much of theoverall insurance claims processing, thus eliminating many of the areasthat are repetitive or prone to human error. These areas include thefollowing:

(a) Filling in the service provider's information. Although eachinsurance company may require something different in the way of serviceprovider information, the AIC software can store consolidated serviceprovider information so that the information need be entered only once.For example, the service provider need only enter his telephone numberonce; the AIC software can reformat this basic information specificallyfor each individual insurance company's form;

(b) Transmitting the PAC application to the correct e-mail address, thuseliminating the errors associated with hand addressing and stamping themailing envelope;

(c) Checking each completed form, i.e., PAC application andPredetermination form, for accuracy and completeness, while it is stillat the provider's office or the insurance company; and

(d) Simultaneously transmitting, archiving, and printing the completedforms, e.g., the PAC application.

It will be appreciated that many such advantages will be evident tothose of ordinary skill in the art from having the requisite PAC formstored in the AIC software on the service provider's computer system210, 240.

Moreover, the AIC system advantageously can be optimized to limitunnecessary information. For example, the system can make use ofscanners 220 which have portions of their scanning area physically orelectronically masked out, which reduces both scanning time andtransmission time by minimizing the size of the digitized x-rayproduced, for example, during step S104. The provisions for the use ofdigital and digitized signatures also eliminates unneeded papershuffling.

It should again be noted that the major improvement in efficiencyattributable to the AIC system results from combining or coordinating anelectronic PAC form with an electronic (digitized) x-ray. Thiselectronic x-ray will have a document identification number assigned toit.

In addition, the AIC system and corresponding method according topreferred embodiments of the present invention provide severalconvenience features which are only possible when using a fullyelectronic filing system. For example, the AIC system facilitatesautomatic acknowledgment by the insurance company that it has receivedthe PAC application. Moreover, the AIC system provides automatictransfer of pertinent information from the PAC application to thePredetermination form. Furthermore, the AIC system components at theinsurance company preferably allow simultaneous viewing of the threedocuments needed to complete the Predetermination form. In addition, theAIC system and requisite software automates the entire transmitting andarchiving processes of the PAC application and the Predetermination format the insurance company.

In some instances, the electronic reuse of the Predetermination form asthe Final Payment Claim form means that the service provider need onlyindicate the date that the procedure was performed and enter the serviceprovider's facsimile or electronic signature. The AIC software module atthe provider's office requests these be entered into P, i.e., thePredetermination form, to create P*, i.e., the Final Payment Claim form,and then transmits P* to the final claims e-mail address for payment.Moreover, the only information that needs to be sent from the serviceprovider to the insurance company is the insurance company's assigneddocument identification number, the date of completion and the serviceprovider's signature.

The preferred embodiments of the AIC system according to the presentinvention provide dentists in the field with the necessary hardware andsoftware which allows them to create an electronic (digital) version ofa patient's PAC application, both the text and the required patientx-ray. The AIC software automatically adds these two data types togetherto form a single entity, the patient's PAC application. Moreover, theAIC system provides the insurance companies with hardware and softwarewhich allows them to read the patient's electronic PAC application. Foreach insurance company, this application is tailored so that it containsthe specific information required by that company and it contains thatinformation in the form required by that company. As such, the necessityto force standard formats on the insurance industry is eliminated.Moreover, the AIC system and software automatically attaches a partiallyfilled out Predetermination form to the patient's PAC application whenit is called up for review and approval. Moreover, the AIC system andsoftware completely eliminates the time consuming process of actuallyhandling the patient's film x-ray by insurance company personnel.

Other modifications to and variations of the invention will be apparentto those skilled in the art from the foregoing disclosure and teachings.Thus, while only certain embodiments of the invention have beenspecifically described herein, it will be apparent that numerousmodifications may be made thereto without departing from the spirit andscope of the invention, as defined in the appended claims.

1. A computer system configured through computer software to present agraphical user interface (GUI) comprising two disjoint sets of labeledfields, a first set and a second set, wherein both the first and secondsets are non-empty sets, and to generate a file from data entered intoat least some of the labeled fields, wherein the computer software isadapted to cause the computer system to construct the generated file bytaking the following actions: establishing in the GUI, responsive toentry of first data into the first set of labeled fields, a first subsetand a second subset of the second set of labeled fields, wherein thefirst subset of the second set of labeled fields is allowed to acceptsecond data and the first subset of the second set of labeled fieldscontains at least one labeled field, and wherein the second subset ofthe second set of labeled fields is inhibited from accepting data, andassigning each field of the second set of labeled fields to one or theother of the first subset and the second subset of the second set oflabeled fields, on the basis of which set of criteria, in apredetermined plurality of sets of criteria, is satisfied by the firstdata entered into the first set of labeled fields, and wherein thegenerated file comprises individually identifiable data fields andwherein at least some of the individually identifiable data fields arefilled with first data or second data.
 2. The computer system as recitedin claim 1, wherein the first set of labeled fields contains two fields.3. The computer system as recited in claim 2, wherein the first set oflabeled fields contains at least two fields with one of the fieldsidentifying a health insurance payer and one of the fields identifying amedical procedure.
 4. The computer system as recited in claim 1, whereinat least one field of the first subset of the second set of labeledfields is automatically filled in when data is entered into the firstset of labeled fields.
 5. The computer system as recited in claim 1,wherein the data entered into at least one field in the GUI isautomatically transferred to a field in another software application. 6.The computer system as recited in claim 1, wherein the file created is ahealth insurance claim.
 7. The computer system as recited in claim 6,wherein the software is integrated with a health care provider'spractice management software.
 8. A computer system configured throughcomputer software to present a graphical user interface (GUI) comprisingtwo disjoint sets of labeled fields, a first set and a second set,wherein both the first and second sets are non-empty sets, and whereinthe labeled fields belonging to the first set are allowed to acceptfirst data, and the labeled fields belonging to second set are allowedto accept second data, and to generate a file, transmittable to aselected one of M possible recipients, from data entered into at leastsome of the labeled fields, wherein the file format for the generatedfile is selected from a predetermined set of R file formats on the basisof which set of criteria, in a predetermined plurality of sets ofcriteria, is satisfied by the first data entered into the first set oflabeled fields, wherein the generated file comprises individuallyidentifiable data fields and wherein at least some of the individuallyidentifiable data fields are filled with first data or second data, andwherein R is an integer equal to or greater than two and M is an integerequal to or greater than two.
 9. The computer system as recited in claim8, wherein the selected one of the M recipients is selected by enteringan unique identifier corresponding to the selected one of the Mrecipients into a field in the first set of labeled fields.
 10. Thecomputer system as recited in claim 8, wherein each of the M recipientshas associated therewith a unique portion of the computer software. 11.The computer system as recited in claim 10, wherein the unique portionof the computer software associated with each of the M recipientscontains information specifying the file format to be used for filesgenerated for transmission to that recipient.
 12. The computer system asrecited in claim 11, wherein the computer system is further configuredto generate the file using the file format specified for the selectedone of the M recipients in response to entering the unique identifiercorresponding to the selected one of the M recipients into a field inthe first set of labeled fields.
 13. The computer system as recited inclaim 10, wherein the unique portion of the computer software associatedwith each of the M recipients is updated: as the file requirements ofthat particular recipient change; independent of the other M recipients;and independent of a sender of the transmitted file.
 14. The computersystem as recited in claim 10, wherein the unique portion of thecomputer software associated with each of the M recipients is accessedand updated by that recipient independently of the remaining Mrecipients and independently of a sender of the transmitted file. 15.The computer system as recited in claim 8, wherein at least some of thedata in the identifiable fields of the transmittable file generated canbe digitally transferred from the generated file to associated fields ofa software application at the selected one of the M recipients.
 16. Thecomputer system as recited in claim 15, wherein at least some of thedata in the identifiable fields of the transmittable file generated canbe digitally transferred from the generated file to associated fields ofa software application at the selected one of the M recipients withoutimposing a standard on the transmittable file which forces every one ofthe M recipients to accept files with the same file format as filesgenerated for all the other M recipients.
 17. The computer system asrecited in claim 15, wherein a sender of the transmitted file cangenerate the transmittable file wherein at least some of the data in theidentifiable fields of the transmittable file generated can be digitallytransferred from the generated file to associated fields of a softwareapplication at the selected one of the M without said recipientdivulging to the sender specifications of its information system. 18.The computer system as recited in claim 8, wherein the M recipients anda sender of the transmitted file operate independent computer systems.19. The computer system as recited in claim 8, wherein the GUI providesa single universal interface between a sender of the transmitted fileand the M recipients.
 20. The computer system as recited in claim 8,wherein the computer software resides on a personal computer operated bya sender of the transmitted file.
 21. The computer system as recited inclaim 20, wherein the computer software is automatically updatedwhenever the file is transmitted to the one of the M recipients.
 22. Thecomputer system as recited in claim 8, wherein the computer softwareresides at a value added service on a server computer accessible to asender of the transmitted file via the Internet.
 23. The computer systemas recited in claim 22, wherein the generated file is transmitted fromthe server to the selected one of the M recipients.
 24. The computersystem as recited in claim 22, wherein the generated file is archived ona computer permitting access to the server.
 25. The computer system asrecited in claim 22, wherein: the file is completed on the server; thecompleted file is downloaded to the accessing computer; and thecompleted file is transmitted to the chosen one of the M recipients fromthe accessing computer.
 26. The computer system as recited in claim 8,wherein a first portion of the second set of labeled fields isautomatically filled in with data when the file is opened.
 27. Thecomputer system as recited in claim 8, wherein a second portion of thesecond set of labeled fields is automatically filled in with data whendata is entered into the first set of labeled fields.
 28. The computersystem as recited in claim 8, where the file generated is a transactionfile to be transmitted to a selected one of the M recipients.
 29. Thecomputer system as recited in claim 28, wherein the generated filecorresponds to a health insurance claim form.
 30. The computer system asrecited in claim 29, wherein at least one of the fields of the secondset of labeled fields requests a health insurance claim form attachment.31. The computer system as recited in claim 29, wherein: the first setof labeled fields contains at least two fields wherein a first labeledfield requests a unique identifier associated with a health insurancepayer and wherein a second labeled field requests a unique codeassociated with a medical procedure.
 32. The computer system as recitedin claim 31, wherein once the first and second labeled fields of thefirst set of fields have been populated with respective data, theremaining labeled fields of the GUI identify additional data theidentified health insurance payer requires to support the claim for thespecified medical procedure.
 33. The computer system as recited in claim29, wherein the software is integrated with a health care provider'spractice management software.
 34. The computer system as recited inclaim 8, wherein at least one of the labeled fields of the second set oflabeled fields accepts a computer file.
 35. The computer system asrecited in claim 8, wherein at least one of the labeled fields of thesecond set of labeled fields accepts a digital image.
 36. The computersystem as recited in claim 8, wherein at least one of the labeled fieldsof the second set of labeled fields accepts a word processor document.37. The computer system recited in claim 8, wherein at least one of thelabeled fields of the second set of labeled fields accepts a digitalgraph.
 38. The computer system as recited in claim 8, wherein at leastone of the labeled fields of the second set of labeled fields accepts adigital sound recording.
 39. The computer system as recited in claim 8,where at least one of the labeled fields of the second set of labeledfields accepts a digitized video signal.
 40. The computer system asrecited in claim 8, wherein first and second files generated duringfirst and second sessions initiated by a user have first and second fileformats permitting at least some of the data in the respectiveidentifiable fields to be transferred to associated fields in softwareapplications operated by first and second ones of the M recipients,respectively.
 41. The computer system as recited in claim 8, whereinthere is a one-to-one mapping between each individually identifiablefield of the generated file containing first data or second data and afilled labeled field of the GUI.
 42. The computer system as recited inclaim 8, wherein the data from at least one of the filled labeled fieldsis automatically transferred to a field in another software application.43. The computer system as recited in claim 8, wherein the softwarecontains the information requirements of the M recipients.
 44. Thecomputer system as recited in claim 8, wherein at least some of the setsof criteria are determined by the M recipients.
 45. A computer systemconfigured through computer software to present a graphical userinterface (GUI) comprising two disjoint sets of labeled fields, a firstset and a second set, wherein both the first and second sets arenon-empty sets, to generate a file, transmittable to a selected one of Mpossible recipients, from data entered into at least some of the labeledfields, wherein the computer software is adapted to cause the computersystem to construct the generated file by taking the following actions:establishing in the GUI, responsive to entry of first data into thefirst set of labeled fields, a first subset and a second subset of thesecond set of labeled fields, wherein the first subset of the second setof labeled fields is allowed to accept second data and the first subsetof the second set of labeled fields contains at least one labeled field,and wherein the second subset of the second set of labeled fields isinhibited from accepting data, and assigning each field of the secondset of labeled fields to one or the other of the first subset and thesecond subset of the second set of labeled fields, on the basis of whichset of criteria, in a first predetermined plurality of sets of criteria,is satisfied by the first data entered into the first set of labeledfields, and specifying in response to the first data entered into thefirst set of labeled fields, a file format for the generated file,wherein the file format for the generated file is selected from apredetermined set of R file formats on the basis of which set ofcriteria, in a second predetermined plurality of sets of criteria, issatisfied by the first data entered into the first set of labeledfields, wherein the generated file comprises individually identifiabledata fields and wherein at least some of the individually identifiabledata fields are filled with first data or second data, and wherein R isan integer equal to or greater than two and M is an integer equal to orgreater than two.
 46. The computer system as recited in claim 45,wherein the selected one of the M recipients is selected by entering aunique identifier corresponding to the selected one of the M recipientsinto a field in the first set of labeled fields.
 47. The computer systemas recited in claim 45, wherein each of the M recipients has associatedtherewith a unique portion of the computer software.
 48. The computersystem as recited in claim 47, wherein the unique portion of thecomputer software associated with each of the M recipients containsinformation specifying the file format to be used for files generatedfor transmission to that recipient and it contains informationspecifying which of the labeled fields in the second set of labeledfields are to be in the first subset of the second set of labeled fieldsfor files generated for transmission to that recipient.
 49. The computersystem as recited in claim 47, wherein the unique portion of thecomputer software associated with each of the M recipients is updated:as the file requirements of that particular recipient changes;independent of the other M recipients; and independent of a sender ofthe transmitted file.
 50. The computer system as recited in claim 47,wherein the unique portion of the computer software associated with eachof the M recipients is accessed and updated by that recipientindependently of the remaining M recipients and independently of asender of the transmitted file.
 51. The computer system as recited inclaim 45, wherein at least some of the data in the identifiable fieldsof the transmittable file generated can be digitally transferred fromthe generated file to associated fields of a software application at theselected one of the M recipients.
 52. The computer system as recited inclaim 51, wherein at least some of the data in the identifiable fieldsof the transmittable file generated can be digitally transferred fromthe generated file to associated fields of a software application at theselected one of the M recipients without imposing a standard on thetransmittable file which forces every one of the M recipients to acceptfiles with the same format and the same individually identifiable fieldsas files generated for all the other M recipients.
 53. The computersystem as recited in claim 51, wherein a sender of the transmitted filecan generate the transmittable file such that at least some of the datain the identifiable fields of the transmittable file can be digitallytransferred from the generated file to associated fields of a softwareapplication at the selected one of the M recipients without saidrecipient divulging to the sender specifications of its informationsystem.
 54. The computer system as recited in claim 45, wherein the Mrecipients and sender of the transmitted file operate independentcomputer systems.
 55. The computer system as recited in claim 45,wherein the GUI provides a single universal interface between sender ofthe transmitted file and the M recipients.
 56. The computer system asrecited in claim 45, wherein the computer software resides on a personalcomputer operated by a sender of the transmitted file.
 57. The computersystem as recited in claim 56, wherein the computer software isautomatically updated whenever the file is transmitted to the one of theM recipients.
 58. The computer system as recited in claim 45, whereinthe computer software resides at a value added service on a servercomputer accessible to a sender of the transmitted file via theInternet.
 59. The computer system as recited in claim 58, wherein thefile generated is transmitted from the server to the selected one of theM recipients.
 60. The computer system as recited in claim 58, whereinthe generated file is archived on a computer permitting access to theserver.
 61. The computer system as recited in claim 45, wherein a firstportion of the first subset of the second set of labeled fields isautomatically filled in with data when the file is opened.
 62. Thecomputer system as recited in claim 45, wherein a second portion of thefirst subset of the second set of labeled fields is automatically filledin with data when data is entered into the first set of labeled fields.63. The computer system as recited in claim 45, where the generated fileis a transaction file to be transmitted to a selected one of the Mrecipients.
 64. The computer system as recited in claim 45, wherein thegenerated file corresponds to a health insurance claim form.
 65. Thecomputer system as recited in claim 64, wherein at least one of thelabeled fields of the first subset of the second set of labeled fieldsrequests a health insurance claim form attachment.
 66. The computersystem as recited in claim 65, wherein the health insurance claim formattachment requested comprises one or more of the following: x-rays,CTs, MRIs, EKGs, EEGs, strip charts, digitized video signals,transcriptions of Operating Room Notes, or additional ASCII text. 67.The computer system as recited in claim 64, wherein: the first set oflabeled fields contains at least two labeled fields wherein a firstlabeled field requests a unique identifier associated with a healthinsurance payer and wherein a second labeled field request a unique codeassociated with a medical procedure.
 68. The computer system as recitedin claim 67, wherein once the first and second labeled fields of thefirst set of labeled fields have been populated with respective data,the remaining labeled fields of the first subset of the second set oflabeled fields identify additional data the health insurance payerrequires to support a claim for the specified medical procedure.
 69. Thecomputer system as recited in claim 45, wherein at least one of thelabeled fields of the first subset of the second set of labeled fieldsaccepts a computer file.
 70. The computer system as recited in claim 45,wherein at least one of the labeled fields of the first subset of thesecond set of labeled fields accepts a digital image.
 71. The computersystem as recited in claim 45, wherein at least one of the labeledfields of the first subset of the second set of labeled fields accepts aword processor document.
 72. The computer system as recited in claim 45,wherein at least one of the labeled fields of the first subset of thesecond set of labeled fields accepts a digital graph.
 73. The computersystem as recited in claim 45, wherein at least one of the labeledfields of the first subset of the second set of labeled fields accepts adigital sound recording.
 74. The computer system as recited in claim 45,wherein at least one of the labeled fields of the first subset of thesecond set of labeled fields accepts a digitized video signal.
 75. Thecomputer system as recited in claim 45, wherein there is a one-to-onemapping between each individually identifiable field of the generatedfile containing first data or second data and a filled labeled field ofthe GUI.
 76. The computer system as recited in claim 45, wherein thedata entered into at least one field in the GUI is automaticallytransferred to a field in another software application.
 77. The computersystem as recited in claim 45, wherein the software is integrated withhealth-care-provider practice management software.
 78. The computersystem as recited in claim 45, wherein the software contains theinformation requirements of the M recipients.
 79. The computer system asrecited in claim 45, wherein at least some of the sets of criteria aredetermined responsive to the information demands of the M recipients.80. The computer system as recited in claim 79, wherein the softwaredisplays one or more messages in the GUI which instruct that the data tobe entered into the labeled fields be the data required by theidentified recipient, wherein each message displayed in the GUI isselected by a logic control device in the software, on the basis ofwhich set of criteria, in a predetermined plurality of sets of criteria,is satisfied by the data entered into at least some of the labeledfields.